feat: add client-grants command resource - #1598
Open
developerkunal wants to merge 7 commits into
Open
Conversation
Add a client-grants command group (list, create, show, update, delete) backed by the go-auth0 v3 Management SDK, giving the CLI full CRUD coverage for client grants. Create supports specific scopes, all scopes (--allow-all-scopes), or no scopes at all, matching the API. It also accepts --subject-type (client, user, anonymous_user); the organization flags are rejected for user and anonymous_user subject types, which the API does not allow. The detail view always shows the subject type, defaulting an empty value to client so it reads clearly. The v3 SDK client grant wrapper replaces the v1 one, and the callers that used it (quickstarts, terraform, test) are moved over. Adds unit tests, commander integration tests and helper scripts, and the generated command docs.
Temporary: allow the integration-tests job to run on PRs targeting feat/go-auth0-v3-migration so the client-grants suite is exercised against the live tenant. Revert before merge.
The detail view now always shows SUBJECT TYPE, which is the widest label, so the label column pads wider than before. Update the expected spacing in the show-table integration test to match.
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## feat/go-auth0-v3-migration #1598 +/- ##
=============================================================
Coverage ? 59.87%
=============================================================
Files ? 124
Lines ? 24176
Branches ? 0
=============================================================
Hits ? 14475
Misses ? 8792
Partials ? 909 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Update and delete now fail fast when a client grant is a system grant (is_system), which Auth0 refuses to modify, instead of surfacing the raw 400 after the whole interactive flow. System grants are also hidden from the update and delete pickers so they can't be selected. The update scope picker now offers the No scopes option too, matching create. Choosing it sends scope: [] so the grant's scopes are cleared, rather than being read as leaving them untouched.
Update now reads the grant's immutable subject type and, like create, skips the organization prompts and request fields for the user and anonymous_user subject types, which Auth0 rejects organization settings on. It also runs the subject-type validation so the flag path fails fast with a clear message. Both create and update now drop the all-scopes option in the interactive picker when the audience is a system API, since Auth0 rejects allow_all_scopes on system APIs.
…opes Add command-level tests for the update system-grant fail-fast, the update subject-type organization guard, and the delete system-grant fail-fast. Also document that a user subject-type grant against the Auth0 Management API takes a fixed current_user scope set that cannot be listed dynamically, so the scopes must be passed inline with --scopes.
Add --default-for (mutually exclusive with --client-id) and --authorization-details-types to client-grants create, and --authorization-details-types to update. Both are selectable interactively, sourced from the audience API, and the audience API is read once and shared between the scope and authorization-details pickers. Skip organization settings for system APIs, which reject them with a reserved_identifier error, and stop sending a stray allow_any_organization when the user never engaged with organization settings. Show the authorization details types in the detail view, truncated like scopes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🔧 Changes
Adds a
client-grantscommand group so the CLI has full CRUD coverage for client grants, backed by the go-auth0 v3 Management SDK.New commands:
auth0 client-grants list— list client grants, filterable by--client-id,--audience,--subject-type,--default-for, and--allow-any-organization.auth0 client-grants create— authorize an application against an API, or create a default grant for a group of clients.auth0 client-grants show— show a single client grant.auth0 client-grants update— change a grant's scopes, organization settings, and authorization details types.auth0 client-grants delete— remove a grant.Create behavior:
--client-id) or a default group (--default-for), which are mutually exclusive and exactly one is required.--default-foracceptsthird_party_clients, and interactively the target is chosen up front with the default-group values sourced from a list so new values become selectable without more code.--authorization-details-typessets the authorization_details types allowed for the grant (Rich Authorization Requests). Interactively these are offered as a multi-select sourced from the audience API, skipping the prompt when the API defines none. It is available on both create and update.--scopes), every scope on the API (--allow-all-scopes), or no scopes at all. An empty scope list is sent to the API as[]rather than being dropped.--subject-typeacceptsclient,user, oranonymous_user. The organization flags (--organization-usage,--allow-any-organization) are rejected for theuserandanonymous_usersubject types, and are not sent for a default grant, because the API does not allow organization settings in those cases.reserved_identifiererror, andallow_any_organizationis only sent when the user actually sets an organization usage or the flag, so a grant that never touches organizations no longer carries a stray value.Display:
clientso it reads clearly, and shows the authorization details types when the grant has any, truncated to the terminal width like the scope list.The v3 SDK client-grant wrapper replaces the v1 one, and the existing callers (quickstarts, terraform export, and the
testcommand) are moved over to it.📚 References
N/A
🔬 Testing
--default-for/--client-idmutual exclusivity, the authorization details types, the organization-settings guards, subject-type validation, and the display views.test/integration/client-grants-test-cases.yaml) covering list, create (specific / all / no scopes), show, update, delete, the--default-forpaths, and the validation failure paths, plus helper scripts.📝 Checklist